Skip to content

clarify wording of match ergonomics diagnostics (rust_2024_incompatible_pat lint and error) #144006

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

dianne
Copy link
Contributor

@dianne dianne commented Jul 16, 2025

Partially addresses #143557:

  • Uses different wording than the Edition Guide chapter, to hopefully stand alone a bit better. Instead of referring to the "default binding mode", it now talks about what can't be written "within elided reference patterns". I ended up going with "elided" instead of "implicit" in hope that it reads bit less like it should behave the same as an explicit reference pattern, but I'm not totally happy with that wording.
  • The explanatory note still points to where the default binding mode was introduced, but only refers to its effect, not what we call it. How that relates to the rest of the diagnostic may still be a bit of a puzzle, but hopefully it isn't too much of one? It also doesn't make sense anymore for the case of & written under a by-ref binding mode, so I've left the note out in that case (but kept the label). It's more cramped, but talking about binding modes would feel like a non-sequitur for the error about & patterns without further explanation.
  • Links to the stable version of the Edition Guide instead of the nightly version. It looks like almost every link to the Edition Guide in diagnostics is to the nightly version, presumably for the same reason as here: the diagnostics were added before the new Edition was stabilized, then never updated. I'll make a separate PR to clean up the others.

This only changes the diagnostic messages, not the code suggestion or the Edition Guide.

r? @Nadrieril or reassign

@rustbot
Copy link
Collaborator

rustbot commented Jul 16, 2025

Nadrieril is not on the review rotation at the moment.
They may take a while to respond.

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jul 16, 2025
@dianne dianne force-pushed the match-ergonomics-jargon branch from b968622 to 6751630 Compare July 16, 2025 07:13
@rustbot
Copy link
Collaborator

rustbot commented Jul 16, 2025

Some changes occurred in match checking

cc @Nadrieril

@dianne dianne force-pushed the match-ergonomics-jargon branch from 6751630 to 981b966 Compare July 20, 2025 13:22
Comment on lines 321 to 327
mir_build_rust_2024_incompatible_pat = {$bad_modifiers ->
mir_build_rust_2024_incompatible_pat = explicit {$bad_modifiers ->
*[true] binding modifiers{$bad_ref_pats ->
*[true] {" "}and reference patterns
[false] {""}
}
[false] reference patterns
} may only be written when the default binding mode is `move`{$is_hard_error ->
} may not be written within elided reference patterns{$is_hard_error ->
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe "explicit binding modifiers may not be mixed with automatic reference elision"? Not great either, we might need an official term for this

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's tricky! I'm avoiding "mixed with" since it's only an error when they're nested; that wording would maybe suggest they can't be used in the same pattern at all. An official term could help, but if it doesn't stand on its own we're still relying on users to read and understand the Edition Guide or Reference.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Though my wording will also not be entirely right either for new match ergonomics, since it would be possible to match on inherited references and reset the default binding mode. I'm not really sure how to capture the nuance there in a succinct and self-contained manner. Maybe it needs more subdiagnostic notes?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, maybe we can keep "elided reference pattern" if there's a label that points to "a reference was elided here" or sth...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can't read that's literally already there x) ok, then we should use the same terminology in both messages:

error: explicit binding modifiers may not be written within elided reference patterns
...
note: matching on a reference type with a non-reference pattern elides the reference

so that users understand the causality between these things. Problem is that this doesn't explain what "eliding a reference" does...

Copy link
Member

@Nadrieril Nadrieril Jul 23, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if we go all-in with the new mental model, this might look like:

error: cannot borrow twice in a pattern
...
note: matching on a reference type with a non-reference pattern makes variables within borrow their targets already

or

error: cannot dereference an implicit borrow
...
note: matching on a reference type with a non-reference pattern causes the contents to be implicitly borrowed

Copy link
Contributor Author

@dianne dianne Jul 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like "implicit borrow"! it's pretty concise, it uses (hopefully?) familiar terminology, and it doesn't require mentioning variables or drawing comparison to alternative syntax. I've pushed an attempt at fleshing it out. the exact wording still needs work, but I think this is a good direction to try. since the message is now specific to which binding modifiers cause problems, I've added a few extra tests to make sure the new formatting works.

implementation-wise, the main error message could maybe also use being moved off of fluent. the rest isn't translatable yet, the error will eventually need reworking, and it's getting pretty unreadable. that'd also mean spreading the formatting over a couple fewer files. it's tough to avoid splitting it up a little on account of it being checked in hir typeck and formatted in thir building, but we could at least move all the thir parts to migration.rs

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Our policy on fluent is "best-effort, the whole initiative is dead anyway" so feel free to move it out if it makes the impl easier.

fmease added a commit to fmease/rust that referenced this pull request Jul 23, 2025
…bank

don't link to the nightly version of the Edition Guide in stable lints

As reported in rust-lang#143557 for `rust_2024_incompatible_pat`, most future-Edition-incompatibility lints link to the nightly version of the Edition Guide; the lints were written before their respective Editions (and their guides) stabilized. But now that Rusts 2021 and 2024 are stable, these lints are emitted on stable versions of the compiler, where it makes more sense to present users with links that don't say "nightly" in them.

This does not change the link for `rust_2024_incompatible_pat`. That's handled in rust-lang#144006.
fmease added a commit to fmease/rust that referenced this pull request Jul 23, 2025
…bank

don't link to the nightly version of the Edition Guide in stable lints

As reported in rust-lang#143557 for `rust_2024_incompatible_pat`, most future-Edition-incompatibility lints link to the nightly version of the Edition Guide; the lints were written before their respective Editions (and their guides) stabilized. But now that Rusts 2021 and 2024 are stable, these lints are emitted on stable versions of the compiler, where it makes more sense to present users with links that don't say "nightly" in them.

This does not change the link for `rust_2024_incompatible_pat`. That's handled in rust-lang#144006.
fmease added a commit to fmease/rust that referenced this pull request Jul 24, 2025
…bank

don't link to the nightly version of the Edition Guide in stable lints

As reported in rust-lang#143557 for `rust_2024_incompatible_pat`, most future-Edition-incompatibility lints link to the nightly version of the Edition Guide; the lints were written before their respective Editions (and their guides) stabilized. But now that Rusts 2021 and 2024 are stable, these lints are emitted on stable versions of the compiler, where it makes more sense to present users with links that don't say "nightly" in them.

This does not change the link for `rust_2024_incompatible_pat`. That's handled in rust-lang#144006.
fmease added a commit to fmease/rust that referenced this pull request Jul 24, 2025
…bank

don't link to the nightly version of the Edition Guide in stable lints

As reported in rust-lang#143557 for `rust_2024_incompatible_pat`, most future-Edition-incompatibility lints link to the nightly version of the Edition Guide; the lints were written before their respective Editions (and their guides) stabilized. But now that Rusts 2021 and 2024 are stable, these lints are emitted on stable versions of the compiler, where it makes more sense to present users with links that don't say "nightly" in them.

This does not change the link for `rust_2024_incompatible_pat`. That's handled in rust-lang#144006.
@dianne dianne force-pushed the match-ergonomics-jargon branch from 981b966 to 271e81f Compare July 24, 2025 12:41
Comment on lines -1153 to +1160
format!("make the implied reference pattern{plural_derefs}{and_modes} explicit")
if self.ref_pattern_count == 1 {
format!("match on the reference with a reference pattern{and_add_modes}")
} else {
format!("match on references with reference patterns{and_add_modes}")
}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure about this in the case where multiple &s need to be added. help: match on the reference with a reference pattern feels okay to me since "the reference" is the reference in the note just above. when multiple references need to be added, changing that to "the references" wouldn't be very clear, but my current workaround help: match on references with reference patterns feels a bit like a prescription to always do that. I'd add more context to relate it to the note explaining implicit borrowing, but then the message gets way too long when also suggesting writing explicit ref/ref mut binding modes.

fmease added a commit to fmease/rust that referenced this pull request Jul 24, 2025
…bank

don't link to the nightly version of the Edition Guide in stable lints

As reported in rust-lang#143557 for `rust_2024_incompatible_pat`, most future-Edition-incompatibility lints link to the nightly version of the Edition Guide; the lints were written before their respective Editions (and their guides) stabilized. But now that Rusts 2021 and 2024 are stable, these lints are emitted on stable versions of the compiler, where it makes more sense to present users with links that don't say "nightly" in them.

This does not change the link for `rust_2024_incompatible_pat`. That's handled in rust-lang#144006.
rust-timer added a commit that referenced this pull request Jul 24, 2025
Rollup merge of #144014 - dianne:edition-guide-links, r=estebank

don't link to the nightly version of the Edition Guide in stable lints

As reported in #143557 for `rust_2024_incompatible_pat`, most future-Edition-incompatibility lints link to the nightly version of the Edition Guide; the lints were written before their respective Editions (and their guides) stabilized. But now that Rusts 2021 and 2024 are stable, these lints are emitted on stable versions of the compiler, where it makes more sense to present users with links that don't say "nightly" in them.

This does not change the link for `rust_2024_incompatible_pat`. That's handled in #144006.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants